home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text1179.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  4.3 KB  |  78 lines
  1.  
  2. Dave Raggett writes:
  3. |  Perhaps we need some structuring elements which determine how a 
  4. |  group of related documents can be sequenced into a form suitable 
  5. |  for printing, along with a way of automatically generating a table 
  6. |  of contents, and an index.
  7.  
  8. In response, Daniel Kehoe writes:
  9. |  >From this point of view, it seems a bad idea to include "structuring  
  10. |  elements" inside documents that tie them together for printing (if  
  11. |  that's what you were suggesting), 
  12.  
  13.   I agree that the idea of "structuring elements" specific to printing is
  14. a bad idea.  It seems to be just another way of sneaking presentation
  15. information into the DTD, something which many seem to agree is a bad idea.
  16.   
  17.   There are many different possible approaches to searching the web and
  18. extracting subsets of it for various purposes.  As architects of the hypertext
  19. infrastructure, our job is to provide an information architecture rich enough
  20. to support any search/pruning method.  We should avoid imposing any particular
  21. interpretation upon the information, but rather enable others to apply their
  22. own interpretations as they see fit.  The author of a document may choose to
  23. publish one or more default organizations along with the information itself,
  24. and readers may choose to select an alternate organization.  So, all we need
  25. in HTML is a *general* way of specifying relationships between documents, which
  26. is what we already have in the REL attribute. 
  27.  
  28.   Note that the list of HTML link relationships is not part of the HTML
  29. standard (see http://info.cern.ch/hypertext/WWW/MarkUp/Relationships.html).
  30. This is good and allows for different standard "sets" of relationship values
  31. to be defined and used.  I am reminded of the "element sets" referred to as
  32. part of ANSI Z39.50 (ISO 10162/10163).  That standard does not require that all
  33. clients or servers support any specific element set.  Rather, each registered
  34. element set has a unique name; the client and server neogiate on the element
  35. set(s) to be used in a session. Several archetypal element sets are defined for
  36. well-defined domains such as bibliographic references, but the protocol itself
  37. does not limit the definition of element sets in general.  In fact, Z39.50
  38. servers can use ASN.1 to describe element sets to clients who would otherwise
  39. not recognize those sets.
  40.  
  41.   Similarly, relationship-sets could be defined for some archetypal forms
  42. which we all use and understand (journals, books, programs, etc.).  For
  43. instance, while we certainly would like the capability to break out the
  44. chapters and other components of a book, it doesn't make sense to speak
  45. of a "chapter" of an animation any more than it does to reference a "frame"
  46. of a book.  So, we use different sets of relationship attributes for different
  47. types of data.  Perhaps we should add a relationship-set specification to the
  48. document header. Something like,
  49.  
  50. <HEADER> <REL-SET NAME="US Book 153.5"> </HEADER>
  51.  
  52. If we allowed relationship-set specification within an anchor tag, then we
  53. could support the use of mulitple relationship-sets within a single document.
  54. For example,
  55.  
  56. <A HREF="http://foo/bar" REL-SET="CERN" REL="Made,REV">Dr. Elmer J. Fudd</A>
  57. <A HREF="http://foo/bar" REL-SET="ISO-Journal 101" REL="ABSTRACT">Abstract</A>
  58. ARTICLE TEXT HERE
  59. <A HREF="http://foo/bar" REL-SET="US-MARC" REL="BIBLIO">References</A>
  60.  
  61. Of course, once we start using different relationship sets, a client may come
  62. across a document containing relationships which it doesn't know about.  This
  63. could be solved using ASN.1 just as is done in Z39.50.  
  64.    
  65.   An alternative approach would be to use multiple DTD's. Why not just
  66. incorporate generic SGML parsing into the browsers and have many "variants" of
  67. HTML.   We could provide a mechanism in the protocol for requesting the URL of
  68. the DTD corresponding to the structure of some other URL and then use that DTD
  69. to interpret the incoming document.  That is, when the user activates a link
  70. to some document, we contact the server specified in the HREF of that link and
  71. rather than requesting the item referenced in the URL, we request the DTD
  72. describing the tags contained in the referenced item.  The server then would
  73. either return the DTD, or a URL for that DTD.  Once we have parsed and perhaps
  74. cached the DTD, we would then request the referenced item and process it
  75. accordingly.  (I hope my ignorance of SGML isn't showing too badly here)
  76.  
  77. Chris
  78.